Quality Requirements Checklist

On an individual requirement by requirement basis, quality requirements are typically much more important than functional requirements because they most strongly drive the architecture of software-intensive systems. Thus, it is how well the quality requirements are engineered and implemented that tends to determine the success or failure of mission critical systems. Yet, missing or poorly specified quality requirements can all too commonly be identified during effective evaluations of the requirements specifications and the resulting architectures. This column provides a short checklist for use during the engineering and evaluation of quality requirements to help the requirements team develop better quality requirements and to help evaluators of these requirements identify defects in the associated requirements specifications. 1 THE CRITICALITY OF QUALITY REQUIREMENTS A great deal of formal and anecdotal evidence exists that the typical quality of actual requirement specifications today is embarrassingly poor. In practice, far too many requirements are ambiguous, incomplete, infeasible, unverifiable, inadequately prioritized, and mutually inconsistent [Firesmith 2003a]. In fact, this poor quality of individual requirements and the requirements specifications that document them is a primary reason why so many projects continue to fail [Standish 1994]. Because so many requirements defects remain in requirements specifications after they have been reviewed and approved, clearly the current approaches as applied in practice being used to develop and review requirements are seriously inadequate to discover and correct these defects. 2 A MAJOR WAY QUALITY REQUIREMENT DEFECTS ARE CURRENTLY IDENTIFIED Unfortunately, the poor quality of the requirements is typically not recognized during requirements engineering and the evaluation of requirements specifications. Due to inadequate customer organization (e.g., the Government or commercial market) experience, training and tool support, the stakeholder (e.g., business, user) requirements typically contain large numbers of defects. These requirements may be internally QUALITY REQUIREMENTS CHECKLIST 32 JOURNAL OF OBJECT TECHNOLOGY VOL. 4, NO. 9 reviewed, but most defects are not found. These stakeholder requirements are then passed on to the development organization (e.g., prime contractor or internal IT), which derives system-level technical requirements. For similar reasons, these technical requirements are typically of poor quality, and a great many defects are not identified when the requirements specifications are duly evaluated during peer-level and more formal milestone reviews. This process continues down the system logical architecture from system to subsystems to subsubsystems and from prime contractors to subcontractors and integrated product teams (IPTs) who are responsible for implementing the allocated requirements. Although many defects are identified and fixed during this process of derivation and evaluation, a vast number of requirements errors still slip through the requirements engineering process into the architecture, design, and implementation. While this passing on of requirements defects is true of all types of requirements, it is especially true of quality requirements. Unfortunately, quality requirements are the primary drivers of the system and subsystem architectures. Only when it becomes time to technically evaluate these architectures does the dismal quality of the quality requirements become obvious. Because quality requirements are the primary drivers of the architecture, an effective architecture assessment must evaluate the architecture against its support (or lack of support) for these architecturally-significant drivers. Because the requirements specifications tend to be extremely week when it comes to properly specifying quality requirements, the assessors of the architecture often find that they cannot properly evaluate the architecture because they do not have adequate requirements against which to assess it. In fact, because assessors of the architecture are so used to dealing with requirements specifications that do not contain adequate architecturally-significant quality requirements, they have been forced out of self defense to take on some of the responsibilities of the requirements team. They have been forced to develop architectural assessment methods that begin with some kind of identification and derivation of these quality requirements. For example, it is largely because requirements teams have consistently failed to adequately specify the quality requirements that Software Engineering Institute (SEI) architects have developed the Quality Attribute Workshop (QAW) to identify and document these critical architectural drivers [SEI 2005]. It is also a major reason why the SEI’s ATAM method begins with steps designed to ensure that the architecturallysignificant quality factors against which to assess the architecture exist [Clements 2002]. But while such approaches are sufficient to enable an assessment of the architecture to take place, they do not replace proper requirements engineering nor are proper quality requirements needed by other stakeholders (e.g., designers, implementers, and testers) specified. As one small step towards ensuring the early existence of adequate quality requirements, this column presents a short checklist of questions to be answered during requirements engineering and the associated evaluations of the requirements.